The Universal Plug and Play (UPnP) standard is designed to enable simple and robust connectivity among stand-alone devices and personal computers (PCs) from many different vendors. With UPnP, a device can dynamically join a network, obtain an Internet Protocol (IP) address, convey its capabilities, and learn about the presence and capabilities of other devices. Devices can subsequently communicate with each other directly, thereby enabling discovery and control of devices. UPnP uses standard Transmission Control Protocol/Internet Protocol (TCP/IP) and Internet protocols which facilitates interoperability with existing networks.
The basic building blocks of a UPnP network are devices, services and control points. A UPnP device is a container of services and nested devices. Different categories of UPnP devices are associated with different sets of services and embedded devices. For instance, services within a video cassette recorder (VCR) are different than those within a printer. The set of services provided by a particular device, as well as a list of properties associated with the particular device, are captured in a device description document that the device must host. This device description document is written in Extensible Markup Language (XML).
A service exposes actions and models its state with state variables. For instance, a clock service can be modeled as having a state variable, current_time, which defines the state of the clock, and two actions, set_time and get_time, which enables control of the service. Similar to the device description, this information is part of a service description document written in XML. The UPnP Forum defines UPnP Device and Service Descriptions according to a common architecture. A pointer, such as a Uniform Resource Locator (URL), to each appropriate service description document is included within a device description document. Devices may include multiple services.
A service in a UPnP device includes a state table, a control server and an event server. The state table models the state of the service through state variables and updates them when the state changes. The control server receives action requests, such as set_time, executes the action requests, updates the state table and returns responses. The event or media server publishes events to interested subscribers anytime the state of the service changes. For instance, a fire alarm service sends an event to interested subscribers when its state changes to “ringing.”
A control point in a UPnP network is a controller capable of discovering and controlling other devices. After discovery of a network device, a control point can retrieve the device description and get a list of associated services, retrieve service descriptions for available services and invoke actions to control the service. The control point can also subscribe to the service's event source such that anytime the state of the service changes, the event server sends an event to the control point.
UPnP uses open, standard protocols such as TCP/IP, HyperText Transport Protocol (HTTP) and XML. Using these standardized protocols aids in ensuring interoperability between vendor implementations. Other technologies can also be used to network devices together. Such technologies include networking technologies such as Home Audio Video Interoperability (HAVi), Consumer Electronic Bus (CEBus), LonWorks, European Installation Bus (EIB), or X10. These too can participate in the UPnP network through a UPnP bridge or proxy.
A conventional protocol stack used to implement UPnP is illustrated in FIG. 1. The protocol stack includes a TCP/IP networking protocol stack 10, an HTTP layer 18, an HTTPU (HTTP unicast over User Datagram Protocol (UDP)) layer 20, an HTTPMU (HTTP multicast over UDP) layer 22, an SSDP (Simple Service Discovery Protocol) layer 24, a GENA (General Event Notification Architecture) layer 26, a SOAP (Simple Object Access Protocol) layer 28, a UPnP Device Architecture Defined layer 30, a UPnP Forum Working Committee Defined layer 32 and a UPnP Vendor Defined layer 34. The TCP/IP protocol stack 10 includes an IP layer 16, a TCP layer 14 and a UDP layer 12. The TCP/IP networking protocol stack 10 serves as the base on which the rest of the UPnP protocols are built. By using the standard, prevalent TCP/IP protocol suite, UPnP leverages the protocol's ability to span different physical media and ensures multiple vendor interoperability. UPnP devices can use many of the protocols in the TCP/IP protocol suite including TCP, UDP, IGMP (Internet Group Multicast Protocol), ARP (Address Resolution Protocol) and IP, as well as TCP/IP services such as DHCP (Dynamic Host Configuration Protocol) and DNS (Domain Name System). TCP/IP provides the base protocol stack for network connectivity between UpnP devices.
All aspects of UPnP build on top of HTTP or its variants. HTTPU and HTTPMU are variants of HTTP defined to deliver messages on top of UDP/IP instead of TCP/IP. HTTPU and HTTPMU are protocols used by SSDP, which is described below. The basic message format used by HTTPU and HTTPMU adheres with that of HTTP and is required both for multicast communication and when message delivery does not require the overhead associated with reliability.
SSDP provides a mechanism for discovering network devices on the network. SSDP is built on HTTPU and HTTPMU and defines methods both for a control point to locate resources on the network, and for devices to announce their availability on the network. By defining the use of both search requests and presence announcements, SSDP eliminates the overhead that would be necessary if only one of these mechanisms is used. As a result, every control point on the network has complete information on network state while keeping network traffic low.
Both control points and devices use SSDP. A UPnP control point, upon booting up, can send a multicast SSDP search request over HTTPMU to discover devices that are available on the network. The control point can refine the search to find only devices of a particular type, such as a VCR, particular services, such as devices with clock services, or even a particular device. UPnP devices listen to the multicast port. Upon receiving a search request, the device examines the search criteria to determine if they match. If a match is found, a unicast SSDP over HTTPU response is sent to the control point. Similarly, a device, upon being connected to the network, sends out multiple SSDP presence announcements advertising itself.
Both presence announcements and unicast device response messages include a pointer to the location of the device description document, which has information on the set of properties and services supported by the device.
The process involved in UpnP networking includes addressing, discovery, description, control, eventing and presentation. UPnP provides support for communication between control points and devices. The network media, the TCP/IP protocol suite and HTTP provide basic network connectivity and addressing. On top of these open, standard, Internet based protocols, UPnP defines a set of HTTP servers to handle discovery, description, control, events and presentation.
Each device includes a DHCP client that searches for a DHCP server when the device is first connected to the network. If a DHCP server is available, the device uses the IP address assigned to it. If no DHCP server is available, the device uses Auto IP to get an address.
Once devices are attached to the network and addressed appropriately, discovery can take place. Discovery is handled by the SSDP, as discussed above. When a device is added to the network, SSDP enables the device to advertise its services to control points on the network. When a control point is added to the network, SSDP enables the control point to search for devices on the network. The fundamental exchange in both cases is a discovery message containing a few, essential specifics about the device or one of its services, for example its type, identifier, and a pointer to its XML device description document.
The next step in UPnP networking is description. After a control point discovers a device, the control point still knows very little about the device. For the control point to learn more about the device and its capabilities, or to interact with the device, the control point must retrieve the device's description from the URL provided by the device in the discovery message.
Devices can include other logical devices and services. The UPnP description for a device is expressed in XML and includes vendor-specific, manufacturer information including the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, and so forth. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing and presentation.
After the control point has retrieved a description of the device, the control point has the essentials for device control. To learn more about the service, the control point must retrieve a detailed UPnP description for each service. The description for a service is also expressed in XML and includes a list of the commands, or actions, the service responds to, and parameters or arguments, for each action. The description for a service also includes a list of variables. These variables model the state of the service at run time, and are described in terms of their data type, range, and event characteristics.
To control a device, the control point sends an action request to a device's service. To do this, the control point sends a suitable control message to the control URL for the service that is provided in the device description. Control messages are expressed in XML using SOAP. In response to the control message, the service returns action specific values or fault codes.
UPnP architecture defines the general interaction between UPnP control points and UPnP network devices containing audio/video (AV) media. The UPnP architecture is independent of any particular device type, content format, and transfer protocol. The UPnP architecture enables a UPnP control point to discover UPnP network devices within a network, and to enumerate the content available on each discovered UPnP network device. Each UPnP network device uses a UPnP Content Directory Service to compile detailed information about each content item on the UPnP network device. Each content item that is referenced by the Content Directory Service includes various information about the content item including the transfer protocol(s) and file format(s) that the UPnP network device storing the content item can use to transfer the content item to another UPnP network device.
In general, a UPnP control point discovers UPnP network devices within a network. The control point interacts with the discovered devices to locate desired content. Once the content is identified, the control point identifies a common transfer protocol and data format that can be used to transfer the content from the UPnP network device on which the content is located and a UPnP network device to which the content is to be transferred. After these transfer parameters are established, the control point controls the flow of content. The actual transfer of the content is performed directly by the two UPnP network devices. The content transfer happens independently from the control point and does not involve the UPnP protocol. The control point uses UPnP to initialize the transfer of the content, but the transfer is performed using a transfer protocol other than UPnP.
Rendezvous is a networking protocol which proposes zero configuration IP networking. The rendezvous protocol allows two or more computers to be brought up on a local area network and without any manual configuration whatsoever, these computers can all see each other, discover available network services and communicate with each other using standard networking protocols. The rendezvous protocol does not require a server within the network. If there is no server within the network, then the devices within the rendezvous network assign themselves non-conflicting IP addresses. The rendezvous protocol utilizes the standard IP networking protocol to enable networking and service discovery.
The rendezvous protocol includes a service discovery feature, allowing computers on the network to find services available on other computers on the network without the need for any central directory server. This allows peripherals, databases, application services and other network services to all be discovered and accessed automatically by computers on the network, without any configuration or static IP assignment whatsoever. The rendezvous protocol specifies domain name services-simple discovery (DNS-SD) as its discovery mechanism. The service discovery and name resolution protocol provided by both of the DNS-SD and multicast DNS make use of existing on-the-wire DNS formats, resource record definitions and namespace. Multicast DNS provides a way to perform multicast DNS queries when there is no DNS server in a local area network. The DNS-SD protocol uses multicast DNS queries to find services and is targeted at ad-hoc networks such as in the home.
There is currently no method or apparatus for bridging devices operating according to UPnP with devices operating according to the rendezvous protocol. Accordingly, there is currently no method or apparatus for connecting devices within a UPnP network with devices in a rendezvous network.